Internet Info 1993

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-fopg-ositransition-00.txt < prev next >

Wrap

Text File | 1993-03-03 | 44.5 KB | 1,581 lines

INTERNET OSI INTEGRATION, COEXISTENCE AND INTEROPERABILITY ISSUES **********DRAFT********** Version 0.1 R. Callon R. Hagens R. Nitzan July 23, 1990 1. Status This working document is a DRAFT intended for review. Com- ments are encouraged. 2. Introduction The intent of this document is to provide technical descrip- tions of the issues involved in the integration of the Open Systems Interconnect (OSI) protocols into the operational networks which interconnect and comprise the "Internet". The issues raised and solutions discussed are a result of the Federal Networking Council (FNC) OSI Planning Group (FOPG). The members of the FOPG represent several Federal Government agencies such as the Department of Energy (DOE), the National Science Foundation (NSF) the National Aeronautics and Space Administration (NASA), the National Institute of Standards and Technology (NIST) under the Department of Com- merce, as well as University experts. The Internet is composed of many networks. Some are funded privately and some are funded by the U.S. Government, yet all currently use the Transport Communications Protocol (TCP)/Internet Protocol (IP) [2,3] and can communicate via some physical connection point. Other networks use dif- ferent protocols that physically connect, yet they are essentially disjoint because the protocols they use do not interoperate transparently with TCP/IP. As both non-TCP/IP networks and the Internet begin to use OSI, the interconnec- tivity expands and hence the size of the Internet. There- fore, OSI integration into the non-TCP/IP networks that interconnect, specifically the large DECnet* networks, is considered as well. *DECnet is a trade mark of Digital Equipment Corporation It is recognized that there is a commitment to integrate OSI DRAFT FOPG-OSI Spec July 23, 1990 into many networks that compose the Internet, however, it must also be recognized that there is typically a higher commitment to continue providing existing network services to users. There are key pieces missing from the OSI infras- tructure such as inter-domain routing, directory/name ser- vice and network management. The missing components coupled with the installed user base of TCP/IP will prevent OSI from supplanting the TCP/IP protocol suite. As a result, in addition to the integration of OSI, there will be coex- istence and interoperability amongst OSI, TCP/IP and poten- tially DECnet for the indefinite future. Despite the current difficulties, there is large momentum behind the OSI development, and it is anticipated to be in wide use eventually. Some of the most optimistic specula- tion has been that OSI will be in predominate use 5 years from now, while the more pessimistic speculation is that it will take another 10 years. The integration and transition of any new protocols into a large established network base will require adjustments or fine tuning to the protocols themselves as well as to how they are used. This is a normal expectation for changes of this magnitude. Throughout this paper an attempt is made to identify the issues and potential problems that will arise as the new OSI protocols are integrated. This is considered an important part of the initial planning stage. 2.1. Scope and Objectives Each administration responsible for their networks may have their own policy and guidelines for the integration of OSI. Due to the diversity of existing administrations, networks, and users, it is nearly impossible to generate a common OSI integration plan. Administrations serving user communities with different requirements may require different solutions that are specific to their particular needs. Therefore, this document does not contain "The OSI Integra- tion Plan". Rather, it attempts to address the various issues and scenarios that may arise in the general case i.e., coexistence and interoperability between TCP/IP and OSI. The objectives of this paper are to provide: + A compendium of coexistence and interoperability issues. + A summary of solutions to the various coexistence and interoperability issues. This includes an analysis of Page 2 DRAFT FOPG-OSI Spec July 23, 1990 each solution as well as an indication of issues that require work and are currently lacking resources. Page 3 DRAFT FOPG-OSI Spec July 23, 1990 3. THE CURRENT AND FUTURE INTERNET It is important to understand the state of the current TCP/IP Internet while analyzing the subsequent issues. The current model of the evolving Internet is based around three components: high speed backbones, large regional networks, and local site networks. The local area networks connect to regional networks. In turn, the regional networks connect to the high speed backbones. There are variations, e.g., some local sites have direct high speed backbone connections, and many regionals interconnect to each other through "backdoor routes". In fact, the number of connections is increasing resulting in a meshed environment, even though there have been successful attempts to consolidate links. The backbones are government funded networks, where some have multi-protocol requirements. For example, both DOE and NASA backbones have multi-protocol mission support require- ments for TCP/IP and DECnet. Most of the backbones are planning to start carrying operational ISO 8473 [] traffic in either 1990 or early 1991. Regional networks, though originally funded by the govern- ment, are tending to become privately operated. Regionals will likely provide operational ISO 8473 forwarding capabil- ities as user requirements become apparent. Most OSI software (including a full OSI stack) can operate on a local area network. However, a lack of user require- ments for operational OSI software has slowed the deployment of OSI on local area networks. 4. Looking Towards OSI Rapid transition from TCP/IP to OSI is not likely to occur. Rather, it is anticipated that an extended period will take place during which both protocol suites will be in widespread use. This will require both coexistence and interoperability between the two protocol suites. 4.1. Coexistence Coexistence among protocol suites occurs when separate pro- tocols run simultaneously on the same network. Coexistence options vary from running dual protocol stacks to operating physically separate networks. Physically separate networks are usually not practical since they require separate circuits, devices, routers and resources in general. This is (typically) incongruous with the strong cost incentive to share physical resources. Page 4 DRAFT FOPG-OSI Spec July 23, 1990 Dual protocol stacks can run in parallel in an end system and/or an intermediate system. Dual protocol (or multiproto- col in general) schemes are usually cost effective because they allow two or more software stacks to share the same physical resources. However, this may lead to an increase in the number of resources required by the machine and in the complexity of the operational management of two essentially separate networks. 4.2. Interoperability Interoperability becomes an issue when the two end points of a communication path do not use the same protocol suite. In this situation, a conversion mechanism is required to bridge the gap between the two protocols. Interoperability issues arise at many layers. For example, two machines may have the same application protocol suite, but have incompatible network layer protocols. On the other hand, two machines may share a compatible network layer pro- tocol, but have incompatible applications. Interoperability may require that the user be aware of the presence of two protocol suites. In the long run, this is unacceptable on a large scale. 4.3. Mixed Protocol Environment In a mixed environment, more than one protocol stack is used. The stack itself may be mixed, e.g., TCP/IP lower layers and OSI upper layers. It may also be an environment where a pure protocol stack is trying to communicate with a mixed or different protocol stack, e.g., an OSI end system trying to communicate with another end system running OSI applications with TCP/IP lower layers. 5. Status of Issues by Protocol Layer The following sections, categorized by protocol layer, dis- cuss OSI and TCP/IP coexistence and interoperability. 5.1. Physical Layer There are no known physical layer issues that need to be resolved. Page 5 DRAFT FOPG-OSI Spec July 23, 1990 5.2. Data Link Layer The Government OSI Profile (GOSIP) Version 2.0 [20] speci- fies 3 data link layer protocols: 1) High Level Data Link Communication (HDLC) Link Access Procedure B (LAP B), in conjunction with X.25 (ISO 7776) and Pt-Pt subnetworks; 2) ISO 8802/2 (LLC 1) in conjunction with ISO 8802/3, ISO 8802/4, or ISO 8802/5; and 3) Q.921 for operation on the ISDN D channel and ISO 7776 (LAP B) for operation on ISDN B channels. The Internet standard data link layer is the Point to Point Protocol (PPP) [22]. 5.2.1. Coexistence Issue: OSI and IP over HDLC Status: resolved. OSI and IP packets may be distinguished on an HDLC link by examining the Network Layer Protocol ID (NLPID) field of the HDLC or X.25 header. NLIPDs have been assigned for IP and ISO 8473. This allows both protocols to run over HDLC or over HDLC/X.25. 5.2.2. Coexistence Issue: OSI and IP over 802.x Status: resolved. OSI and IP packets may be distinguished on 802.2 links by examining the Destination Service Access Point (DSAP) field in the 802.2 header. DSAP values have been assigned for OSI packets as well as IP packets. 5.2.3. Coexistence Issue: OSI and IP over PPP Status: work and resources needed. PPP indicates what type of protocol follows in a field within the PPP header. Currently a value is defined indi- cating IP as the next layer protocol. There is some minimal work needed to specify a next level protocol value indicat- ing ISO 8473. 5.3. Network Layer Several pieces of the OSI network layer such as the specifi- cation of CLNP, and the ES-IS routing protocol are complete and provide the transmission of OSI network layer data over local area networks. However, for the network layer to be used on a wide scale, IS-IS routing protocols must be Page 6 DRAFT FOPG-OSI Spec July 23, 1990 deployed. 5.3.1. Operational Issue: OSI Intra-domain IS-IS protocol Status: in progress. The IS-IS intra-domain dynamic routing protocol [25] is currently a Draft Proposal in the ISO/IEC standards organi- zations. IS-IS for ISO 8473 is being progressed rapidly, and is anticipated to become an International Standard in 1991. 5.3.2. Coexistence Issue: Integrated or Parallel Intra- domain protocols Status: work and resources needed. Widespread deployment of both IP and CLNP require the opera- tion of a routing protocol. Two basic approaches to this problem have been identified. In the integrated approach,a single routing protocol is deployed which supports the rout- ing of both IP and CLNP packets. In the Parallel approach, two distinct, independent protocols are operated. A detailed analysis of these two approaches is required. This analysis must address the advantages and disadvantages of each approach and recommend the conditions when each approach is favorable. 5.3.3. Operational Issue: Intra-domain IS-IS for Dual Use Status: in progress. The IETF IS-IS working group is working on integrated rout- ing for both IP and ISO 8473. There is an Internet Draft RFC which is expected to become an RFC in mid 1990. 5.3.4. Operational Issue: Inter-domain Routing Status: in progress, resources needed. There is a draft specification of an Inter-Domain Routing Protocol (IDRP) for consideration as the U.S. contribution to the ISO/IEC standards committees. The previous efforts by ECMA and the development of the Boarder Router Protocol (BRP) contributed to form the basis for this IDRP. There is also an Internet effort for inter-domain routing based on source routing. It has the added feature of policy Page 7 DRAFT FOPG-OSI Spec July 23, 1990 based routing. It is not clear how these two efforts can relate to each other. Static, manually updated tables will be used in the short term for inter-domain routing in an ISO 8473 Internet. This will be required until there is either an International Standard for an IDRP or until an interim IDRP is agreed upon, implemented and commercially available. Static tables are unacceptable on a large scale because of the requirement for human intervention to re-route traffic in the event of link failure, and because of the extra bur- den caused in maintaining large routing tables manually. It is expected that the lack of an IDRP will greatly reduce the deployment of the OSI Connectionless Network Service (CLNS). Thus, there is an urgent requirement for an interim IDRP agreement and implementation. 5.3.5. Operational Issue: NSAP Format Status: in progress. Structure for the Domain Specific Part (DSP) of the Network Service Access Point (NSAP) address has been defined in GOSIP Version 2.0. The GOSIP format is solidified pending GOSIP Version 2.0 final release. (GOSIP Version 1.0 [] will have errata that specifies the GOSIP Version 2.0 NASAP address format.) The lower portion of the DSP has structure that is compatible with the IS-IS intra-domain routing protocol requirements. The GOSIP Version 2.0 format should be used for those administrations which are getting their address assignments from the US government address space. ANSI also assigns NSAPS with a format that has no structure imposed on the DSP. These addresses will be used by non- government networks. A common structure such as defined in GOSIP Version 2.0 should be adopted and used. 5.3.6. Operational Issue: NSAP Guidelines Status: in progress. The NSAP working group in the IETF is working on guidelines regarding OSI addressing. Results may be submitted to the OSI Implementors Workshop and become part of the GOSIP Users' Guide for GOSIP Version 2.0. See Appendix ? for details of these guidelines. Page 8 DRAFT FOPG-OSI Spec July 23, 1990 5.3.7. Operational Issue: ISO 8473 Echo Status: in progress. The IETF has completed work on an ISO 8473 echo function [23]. It must be supported in order to get it through the ISO/IEC standards committees. This Protocol is considered a vital tool for simple network operational support. 5.3.8. Coexistence Issue: CLNS/CONS Interoperability Status: in progress, resources needed. It is anticipated that there will be wide spread use of the connection-less and connection-oriented network services. A solution to this problem must be reached. An ISO technical report [21] specifies a possible solution. 5.4. Transport Layer Transport relays (or gateways or bridges) have been proposed as both a coexistence and an interoperation strategy. This is discussed in a later section. 5.5. Session and Presentation No work is needed. The Session and Presentation Layers for the OSI suite operate independently of the TCP/IP suite. 5.6. Electronic Mail There are several issues relating to the operation of X.400 (the OSI electronic mail system) and coexistence of X.400 and RFC 822 mail systems. 5.6.1. Operational Issue: X.400 routing Status: in progress. There is some work in the NIST X.400 SIG on routing of X.400 messages between MTAs. <TODO: get info from stef on this> 5.6.2. Interoperation Issue: An X.400/RFC 822 gateway Status: in progress. The specification of an RFC 822/X.400 gateway is RFC 987/RFC Page 9 DRAFT FOPG-OSI Spec July 23, 1990 1148 5.6.3. Operational Issue: Structure of X.400 addresses Status: in progress, resources needed. In order to deploy X.400 in the Internet, Internet X.400 users must be given X.400 addresses. How should these addresses be constructed? The two basic choices are to con- struct X.400 addresses based upon X.400 naming guidelines, or to construct X.400 addresses based upon existing RFC 822 addresses. In general, the recommended practice is to create X.400 addresses that are meaningful to the organization (and without regard to any preassigned RFC 822 addresses). 5.6.4. Operational Issue: Use of the PRMD/ADMD field Status: needs work, resources needed. The US must make a policy decision on the use of blank ADMD fields and the registration of PRMD names. Lack of a national policy regarding these attributes will lead to chaos as government, private, and public X.400 networks become interconnected. An initiative with the US State Department (Study Groups A- D) has been formed to oversee the creation of the proper committee to study this issue. (See Stef). 5.6.5. Interoperation Issue: Identification of the users Status: in progress, resources needed. A small but growing population of users in the U.S. Internet are starting to use X.400. These X.400 users must be addressable by RFC822 mail users. RFC987 and RFC1148 gate- ways exist that allow translation and mapping between X.400 and RFC822 messages. One strategy that European countries have taken is to define MX records that appear to be normal RFC822 addresses, but which actually point to an RFC987/1148 gateway to translate messages into the X.400 world. This gives X.400 users an Internet-style address that is concise, easy to type, and consistent with tradition Internet addresses. Another strategy is to embed the X.400 address within the RFC 822 syntax. Page 10 DRAFT FOPG-OSI Spec July 23, 1990 Looking toward the future, it would be delightful if a user could use a common, natural address syntax for all mail, whether sent to an X.400 system, or to an RFC 822 system. The X.500 directory is a key to this situation. A strategy for the Internet must be discussed and docu- mented. 5.6.6. Operational Issue: 987/1148 mapping table support Status: in progress, resources needed. Complex operation of an 987/1148 gateway requires the global distribution of static address mapping information. The current practice of manual distribution will not scale. An experimental use of the DNS to store the mapping information has been undertaken at the University of Wisconsin. Storage of the mapping information in the DNS allows the information to be stored in a distributed manner. The use of the DNS to support RFC 987/1148 mapping informa- tion must be reviewed and documented. 5.6.7. Operational Issue: 987/1148 gateway security Status: work and resources needed. There is considerable work in both the Internet (RFC 822) community and the ISO (X.400) community on security for electronic mail. It does not appear that there has been any serious study of how a mail gateway affects the two security models. 5.7. Virtual Terminal Protocol Status: This section needs to be reviewed by a VTP expert The Virtual Terminal Protocol VTP is the OSI version of remote login. There has been a VTP profile written, that is similar to the Internet TELNET protocol. There currently is an implementation of this, where both the OSI VTP and the Internet TELNET can run in the same host. This results in an application relay running directly in the host, thereby by- passing the added complication of determining where the application gateway is located. A user can login to the host via either VTP or TELNET and from there perform addi- tional remote logins to other machines with either TELNET or VTP. There is also another profile which is more in tune with the Page 11 DRAFT FOPG-OSI Spec July 23, 1990 International Telegraph and Telephone Consultative Committee (CCITT) recommendation for the terminal standard X.3, X.28, and X.29. The functionality is very similar to TELNET. In addition, there is a third generic VTP profile. In regards to the user locating the application gateway, one solution is to require a two step login. The user expli- citly logs into the application gateway via VTP or TELNET and from there uses TELNET or VTP to get to another destina- tion. 5.8. File Transfer Status: This section needs to be reviewed by a FTAM expert There is <??> work being done on an application gateway between the OSI File Transfer, Access and Management (FTAM) [] and the Internet File Transfer Protocol (FTP) []. As in the VTP and TELNET scenario, it is feasible for a user use a two step approach. For file transfer it is a burden since multiple file transfers may be executed in a login session as well as in application software. 6. Issues Spanning Multiple Layers 6.1. Directory Services 6.1.1. Operational Issue: organization of the name space Status: work and resources needed. Currently there is work being done in the X.500 OSI Imple- mentors Workshop. In addition, an IETF X.500 working group has been started. 6.1.2. Coexistence Issue: Multi-Stack protocol selection Status: work and resources needed. A dual stack end system must select which protocol stack to use when trying to get to a specific remote location via directory service query. Thus, the directory system must contain information to aid in protocol stack selection. In addition, the directory must provide some aid in the inden- tification a gateway if the two end systems do not share a common protocol stack. This topic is in the scope of the IETF X.500 working group. Page 12 DRAFT FOPG-OSI Spec July 23, 1990 6.1.3. Coexistence Issue: Interoperability between X.500 and the Internet DNS Status: work and resources needed. This topic is in the scope of the IETF X.500 working group. 6.2. Security, Access Control and Authentication Status: work and resources needed. Multi-protocol secuity issues have not been studied. How- ever, it is likely that multi-stack interoperability prob- lems will result if the security for IP-only environments and security for OSI-only environments is not integrated. Coordination between the IP and OSI security efforts is necessary to ensure security when trying to interoperate between the two electronic mail services. 6.3. Network Management Status: dazed and confused. The IETF is defining how to use the Simple Network Manage- ment Protocol (SNMP) to manage pure OSI systems. This is likely to lead to confusion. This section needs review by an expert in network manage- ment. 6.4. Summary of the Status The following table summarizes the status of the work at various levels. Page 13 DRAFT FOPG-OSI Spec July 23, 1990 Layer/Issue Current Responsible Status Group/Person Datalink + OSI & IP over Ethernet/802.2,3,4 DONE + OSI & IP over HDLC/LAPB DONE + OSI & IP over X.25 DONE + OSI & IP over PPP WORK NEEDED IETF WG Routing + IS-IS for OSI only IN PROGRESS ANSI/ISO + IS-IS for OSI and IP (dual) EXPERIMENTALIS-IS WG + Inter-Domain Routing IN PROGRESS ANSI + Coexistence analysis WORK NEEDED IETF Network + NSAP address format DONE + NSAP guidelines IN PROGRESS NSAP WG/NIST + ISO 8473 Echo IN PROGRESS ANSI/ISO + CLNS/CONS Interoperating IN PROGRESS ANSI/ISO Electronic mail + X.400 Routing IN PROGRESS NIST X.400 SIG + RFC 822/X.400 Gateway EXPERIMENTALIETF + O/R Address Format WORK NEEDED + PRMD/ADMD Field WORK NEEDED + User Identification IN PROGRESS IETF + 987/1148 support IN PROGRESS IETF + Gateway Security WORK NEEDED Virtual Terminal File Transfer Directory Services + Name space IN PROGRESS NIST/IETF + Multi-stack query WORK NEEDED IETF X.500 WG + X.500/DNS interoperation WORK NEEDED IETF X.500 WG Security and Access Control + Dual environments WORK NEEDED Network Management + CMIP/SNMP WORK NEEDED Mixed Stack + ISODE ? 7. Strategies and Scenarios In the follow sections, various coexistence scenarios are examined. Each scenario is defined by type of the source and destination protocol stack. In order to keep the combi- nations under control, the following types of protocol stacks are defined: Page 14 DRAFT FOPG-OSI Spec July 23, 1990 Network Layer Application Suite TCP/IP OSI TCP/IP Internet CLNS-OSI OSI CONS-OSI OSI The combination of TCP/IP Network Layers and OSI applica- tions is accomplished according to RFC 1006 [24]. This mechanism operates the TP0 protocol, along with a simple packetization protocol on top of the TCP/IP, which is used as a connection-oriented network service. With the RFC 1006 approach, OSI applications can establish a connection over any TCP/IP network. The first stack definition (TCP/IP Network Layers, OSI Applications) includes both an RFC 1006 mixed stack and a pure stack OSI system connected to an OSI LAN (where the LAN is surrounded by TCP/IP-only capable routers). Of the possible 16 possible combinations of source and des- tination pairs, some are non-issues since they do not result in a mixed stack environment, such as a TCP/IP host communi- cating with another TCP/IP host over an IP network. The important cases are: Case Source Destination Stack Stack 1 [TCP/IP Net, Internet Appl] [TCP/IP Net, OSI Appl] 2 [TCP/IP Net, Internet Appl] [CLNS-OSI Net, OSI Appl] 3 [TCP/IP Net, OSI Appl] [CLNS-OSI Net, OSI Appl] 4 [TCP/IP Net, OSI Appl] [CONS-OSI Net, OSI Appl] 5 [CLNS-OSI Net, OSI Appl] [CONS-OSI Net, OSI Appl] These are only the simplest of cases. More complicated tran- sit cases may arise where different networks are in the mid- dle. These cases are discussed in a later section. 7.1. Case 1 This case requires an application layer gateway. Page 15 DRAFT FOPG-OSI Spec July 23, 1990 7.2. Case 2 Case two requires an application gateway with the added bur- den of an interoperability problem at the network layer. The most likely solution to this problem requires an application gateway with two network layer protocols (IP Net and CLNS- OSI Net). ADVANTAGES: o No modification to the end system software DISADVANTAGES: o Performance degradation, especially apparent in interac- tive mode. o Locating the application gateway is an issue for the end system. o Functionality loss if one application has greater capabil- ities and hence do not map to the other application. 7.3. Case 3 Case three can be solved with a transport relay (or network layer encapsulation if the [TCP/IP Net, OSI App] really is a pure OSI system isolated in a TCP/IP internet). 7.3.1. A Transport Relay Transport relaying can be used when two end systems are run- ning common applications and the lower layer protocols (up to and including the transport layer) are different. The transport relay converts one lower layer stack to another stack, mapping relevant information between the protocols. All traffic must explicitly go through a transport service relay at the boundary where the underlying network services differ. There are several cases that need this type of capability. For example, an end system running TCP/IP lower layers and OSI applications communicating with an end system running OSI lower layers (CONS or CLNS) and OSI applica- tions. ADVANTAGES: o Interoperability between OSI upper layers over a TCP/IP lower layer network. o Complete transparency to the OSI upper layers Page 16 DRAFT FOPG-OSI Spec July 23, 1990 DISADVANTAGES: o The end system must modify its transport service. o Locating the relay is an issue that requires static tables or a new protocol. o End-to-end packet encryption incurs a security compromise. This is because the encryption algorithm must be re-computed in the relay which requires knowledge of the encryption key. A relay having knowledge of an encryption key is the secu- rity risk. o End-to-end guarantee of non-corrupted data is compromised. A packet having a data error while in the transport relay will get through without notice since the checksum is recom- puted using a different checksum algorithm. 7.3.2. Network Layer Encapsulation An ISO 8473 packet may be encapsulated in an IP packet. Specifically, the ISO 8473 protocol runs above the IP layer. Once encapsulated, the ISO 8473 portion is treated as data by the IP layer and is indistinguishable from any other IP packet. The encapsulated ISO 8473 packet may be forwarded through any IP router. When the IP portion is removed (de- encapsulated), leaving the ISO 8473 packet intact, it appears to the OSI network layer as if it has traversed a single subnetwork. This scheme is useful when an isolated CLNS LAN must traverse a TCP/IP based internetwork on its way to an CLNS based destination. This scheme is most efficient when only one system (an IS) on the LAN is allowed to encapsulate/decapsulate. ADVANTAGES: o Interoperability between OSI upper layers over a TCP/IP lower layer network. o Complete transparency to the OSI upper layers o No modification to the end system software, unless the end system is the encapsulator. DISADVANTAGES: o Deriving encapsulators' and de-encapsulators' IP addresses from NSAP addresses requires static tables or a new protocol. Page 17 DRAFT FOPG-OSI Spec July 23, 1990 7.4. Case 4 Case four can be solved with a transport relay. 7.5. Case 5 Case five can be solved with a transport relay. 7.6. More complicated transit situations In all of the solutions that facilitate interoperability and coexistence, there is a question as to what the result will be when the situation becomes complex. For example, con- sider two end systems where the path between them transits several networks, some OSI (both X.25 and ISO 8473) and some TCP/IP. At what point does the solution break? How many cases is it reasonable to analyze? Here are several: Case 6: [OSI Net, OSI Appl] <-> [TCP/IP TRANSIT] <-> [OSI Net, OSI Appl] Case 7: [TCP/IP Net, Internet Appl] <-> [OSI TRANSIT] <-> [OSI Net, OSI Appl] Case 8: [TCP/IP Net, Internet Appl] <-> [OSI TRANSIT] <-> [TCP/IP Net, OSI Appl ] Case 9: [TCP/IP Net, OSI Appl] <-> [OSI TRANSIT] <-> [TCP/IP TRANSIT] <--> [OSI Net, OSI Appl] Case 6 is best handled by network encapsulation. Case 7 requires an application gateway at the edge of the OSI TRAN- SIT network. Case 8 requires both an application gateway and network encapsulation (IP within CLNP). In case 9, if the [TCP/IP Net, OSI Appl] is really an isolated pure OSI stack, then encapsulation across the TCP/IP TRANSIT is all that is required. If the [TCP/IP Net, OSI Appl] is an RFC 1006 host, then both IP encapsulation and a transport service bridge may be required. These situations can generally be broken down by the follow- ing guidelines. If the application changes, then an appli- cation gateway is required. When an application gateway is required and the network service is incompatible, it is best to locate the application gateway at the point where the network service changes. If an application gateway is not required then the network service is the primary consideration. If the network service Page 18 DRAFT FOPG-OSI Spec July 23, 1990 is the same at both ends of the connection, then it is best to use network layer encapsulation. Otherwise, if the net- work service is different at both ends, a transport relay is required. 8. CURRENT STATUS OF OSI IN THE INTERNET 8.1. NATIONAL BACKBONES Most of the national backbone networks plan to start provid- ing limited Connectionless Network Service (CLNS) in late 1990 or early 1991. Some of the agency backbones are upgrading DECnet Phase IV to DECnet Phase V, which includes ISO 8473 end to end service. There are two issues to resolve before most of the backbones can provide operational ISO 8473: (1) routing domain boun- dary designation and (2) address registration and dissemina- tion. Until IS-IS dynamic intra-domain routing, network management and directory service is available commercially, limited operational capabilities can be expected for some networks. Page 19 DRAFT FOPG-OSI Spec July 23, 1990 9. APPENDIX A 9.1. DEFINITION OF ACRONYMS ADMD Administrative Management Domain AFI Authority and Format Identifier BRP Boarder Router Protocol CCITT International Telegraph and Telephone Consultative Committee CLNP Connectionless Network-layer Protocol CLNS Connectionless Network Service CMIP Common Management Information Protocol CONS Connection-Oriented Network Service DCC Data Country Code DECnet Digital Equipment Corporation Network DNS Distributed Name Service DSP Domain Specific Part DOE Department of Energy ECMA European ?? ES End System FNC Federal Networking Council FOPG Federal Networking Council OSI Planning Group FTAM File Transfer, Access and Management FTP File Transfer Protocol GOSIP Government Open System Interconnect Profile HDLC High level Data Link Control IDRP Inter Domain Routing Protocol IEC International Electrotechnical Committee IETF Internet Engineering Task Force IP Internet Protocol ISO International Organization for Standards NASA National Aeronautics and Space Administration NIST National Institute of Standards and Technology NSAP Network Service Access Point OSI Open Systems Interconnection OSPF Open Shortest Path First PPP Point-to-Point Protocol RFC Request For Comment SNMP Simple Network Management Protocol TCP Transport Communications Protocol VTP Virtual Terminal Protocol Page 20 DRAFT FOPG-OSI Spec July 23, 1990 10. REFERENCES [1] "U.S. Government Open Systems Interconnections Profile". August 1988. U.S. Federal Information Processing Standards Publication 146. Version 1. [2] J.B Postel, "Internet Protocol", Request For Comment #791, September 1981. DDN Network Information Center, SRI International. [3] J.B Postel, "Transmission Control Protocol", Request For Comment #793, September 1981. [4] ISO 7498 "Basic Reference Model for Open Systems Inter- connection" [5] ISO/IEC 8473, Information Processing Systems, "Protocol for Providing the Connectionless-mode Network Service and Provision of Underlying Service". May, 1987. [6] M.T. Rose, D.E. Case, "ISO Transport on Top of the TCP", Request For Comment #1006, 1987 June. DDN Network Informa- tion Center, SRI International. [7] ISO/IEC 8571-1 Information Processing Systems - "File Transfer, Access and Management Part 1: General Introduc- tion". April, 1988. [8] J.B. Postel, J.K. Reynolds, "File Transfer Protocol", Request For Comment #959, 1985 October. DDN Network Informa- tion Center, SRI International. [9] CCITT Recommendation X.400 (Red Book, 1984), "Message Handling Systems: Systems Model-Service Elements". [10] J.B. Postel, "Simple Mail Transfer Protocol", Request For Comment #821, August 1982. DDN Network Information Center, SRI International. [11] Information Processing Systems, "Virtual Terminal Ser- vice: Basic Class", August, 1987. Draft International Stan- dard 9040. [12] J.B. Postel, J.K. Reynolds, "Telnet Protocol Specifica- tion", May 1983. DDN Network Information Center, SRI Inter- national. [13] Marshall T. Rose. "The Open Book - A Practical Perspec- tive on OSI". Prentice Hall, Englewoods Cliffs, 1990. ISBN 0-13-643016-3. [14] Tim Boland. "Government Open Systems Interconnection Profile Users' Guide". August, 1989. NIST Special Page 21 DRAFT FOPG-OSI Spec July 23, 1990 Publication 500-163. [15] "Digital Network Architecture (Phase V)". September, 1987. Digital Equipment Corporation. Maynard, Massachusetts [16] ISO/IEC JTC 1/SC6/N4945:1989, Telecommunications and Information "Exchange Between Systems, Intra-Domain IS-IS Routeing Protocol" [17] J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin, "Sim- ple Network Management Protocol", Request For Comment #1098, April 1989. DDN Network Information Center, SRI Interna- tional. [18] J. Moy, "Open Shortest Path First", Request For Comment #1131, 1989 October. DDN Network Information Center, SRI International. [19] "Stable Implementation Agreements for Open Systems Interconnection Protocols", Version 2 Edition 4. September, 1989. NIST Special Publication 500-162. [20] "U.S. Government Open Systems Interconnections Pro- file". July 1988. U.S. Federal Information Processing Stan- dards Publication 146. Draft Version 2. [21] ISO/DTR 10172: Information Processing Systems - Data Communications - Network/Transport Protocol Interworking Specification. [22] "Point to Point Protocol", Request For Comment #?, 1989. DDN Network Information Center, SRI International [23] RFC 1139 [24] RFC 1006 [25] ISO/DP 10589: Information Processing Systems - Data Communications - Intermediate system to Intermediate system Intra-Domain routing exchange protocol for use in Conjunc- tion with the Protocol for providing the COnnectionless-mode Network Service (ISO 8473). [] NLPID Page 22 DRAFT FOPG-OSI Spec July 23, 1990 TABLE OF CONTENTS Section 1 Status ...................................... 1 Section 2 Introduction ................................ 1 Section 2.1 Scope and Objectives ...................... 2 Section 3 THE CURRENT AND FUTURE INTERNET ............. 4 Section 4 Looking Towards OSI ......................... 4 Section 4.1 Coexistence ............................... 4 Section 4.2 Interoperability .......................... 5 Section 4.3 Mixed Protocol Environment ................ 5 Section 5 Status of Issues by Protocol Layer .......... 5 Section 5.1 Physical Layer ............................ 5 Section 5.2 Data Link Layer ........................... 6 Section 5.2.1 Coexistence Issue: OSI and IP over HDLC ............................................. 6 Section 5.2.2 Coexistence Issue: OSI and IP over 802.x ............................................ 6 Section 5.2.3 Coexistence Issue: OSI and IP over PPP .................................................. 6 Section 5.3 Network Layer ............................. 6 Section 5.3.1 Operational Issue: OSI Intra-domain IS-IS protocol ................................... 7 Section 5.3.2 Coexistence Issue: Integrated or Parallel Intra-domain protocols .................. 7 Section 5.3.3 Operational Issue: Intra-domain IS-IS for Dual Use ..................................... 7 Section 5.3.4 Operational Issue: Inter-domain Routing .......................................... 7 Section 5.3.5 Operational Issue: NSAP Format .......... 8 Section 5.3.6 Operational Issue: NSAP Guidelines ...... 8 Section 5.3.7 Operational Issue: ISO 8473 Echo ........ 9 Section 5.3.8 Coexistence Issue: CLNS/CONS Interoperability ................................. 9 Section 5.4 Transport Layer ........................... 9 Section 5.5 Session and Presentation .................. 9 Section 5.6 Electronic Mail ........................... 9 Section 5.6.1 Operational Issue: X.400 routing ........ 9 Section 5.6.2 Interoperation Issue: An X.400/RFC 822 gateway .......................................... 9 Section 5.6.3 Operational Issue: Structure of X.400 addresses ........................................ 10 Section 5.6.4 Operational Issue: Use of the PRMD/ADMD field .................................. 10 Section 5.6.5 Interoperation Issue: Identification of the users ..................................... 10 Section 5.6.6 Operational Issue: 987/1148 mapping table support .................................... 11 Section 5.6.7 Operational Issue: 987/1148 gateway security ......................................... 11 Section 5.7 Virtual Terminal Protocol ................. 11 Section 5.8 File Transfer ............................. 12 Section 6 Issues Spanning Multiple Layers ............. 12 Section 6.1 Directory Services ........................ 12 Page 23 DRAFT FOPG-OSI Spec July 23, 1990 Section 6.1.1 Operational Issue: organization of the name space ....................................... 12 Section 6.1.2 Coexistence Issue: Multi-Stack protocol selection ............................... 12 Section 6.1.3 Coexistence Issue: Interoperability between X.500 and the Internet DNS ............... 13 Section 6.2 Security, Access Control and Authentication ................................... 13 Section 6.3 Network Management ........................ 13 Section 6.4 Summary of the Status ..................... 13 Section 7 Strategies and Scenarios .................... 14 Section 7.1 Case 1 .................................... 15 Section 7.2 Case 2 .................................... 16 Section 7.3 Case 3 .................................... 16 Section 7.3.1 A Transport Relay ....................... 16 Section 7.3.2 Network Layer Encapsulation ............. 17 Section 7.4 Case 4 .................................... 18 Section 7.5 Case 5 .................................... 18 Section 7.6 More complicated transit situations ....... 18 Section 8 CURRENT STATUS OF OSI IN THE INTERNET ....... 19 Section 8.1 NATIONAL BACKBONES ........................ 19 Section 9 APPENDIX A .................................. 20 Section 9.1 DEFINITION OF ACRONYMS .................... 20 Section 10 REFERENCES ................................. 21 Page 24